Support Worker API on mingw if winpthread is present #440
Conversation
|
Not a fan of winpthreads. I'd rather add native threads compatibility, like we did for other locking primitives to unlock cross platform Atomics. That would also work on Windows with MSVC for example. |
Agreed, but this probably shouldn't be framed as being about winpthreads specifically - more that the behaviour should be enabled based on feature detection instead of OS How about I change this to cmake setting |
|
It's not pthread specific, I just don't want to have 2 separate implementations on Windows. |
|
Fair enough |
|
Thanks for understanding 🙏 If you want to take a look, my plan is to port the thread implementation from libuv, like the locks and such. Then port the worker API to use that new js_thread_* family of APIs. Having the 262 runner ported is a separate goal IMHO, since it uses more Unix APIs we'd need to add. |
This PR enables the Worker API on Windows if the winpthreads library is available in mingw (usually installed by default as a dependency of gcc/clang), which is already checked as part of cmake's
find_package(Threads)call.The only part that I'm unsure about is that mingw does not have a native
pipe()function - so I've wrapped the Windows_pipe()for compatibility